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The development of systems engineering and 
program management in NASA manned 
space programs has grown in a largely un- 
coordinated manner over the last 30 years. 
However, the systems and practices that 
have been developed form a proven pattern 
for successfully integrating large, technical- 
ly complex programs executed in several geo- 
graphical locations. This development has 
not been recorded in a comprehensive man- 
ner, and much of the reasoning behind the 
decisions made is not obvious. 

For the purposes of this discussion, sys- 
tems engineering is defined as the inter- 
disciplinary engineering that is necessary to 
achieve efficient definition and integration 
of program elements in a manner that meets 
the system-level requirements. Integration 
is defined as the activity necessary to de- 
velop and document the systems’ technical 
characteristics, including interface control 
requirements, resource reporting and analy- 
sis, system verification requirements and 
plans, and integration of the system 
elements into the program operational 
scenario. 

This paper discusses the history of SE&I 
management of the overall program archi- 
tecture, organizational structure and the 
relationship of SE&I to other program orga- 
nizational elements. A brief discussion of the 
method of executing the SE&I process, a 
summary of some of the major lessons 
learned, and identification of things that 
have proven successful are included. 

HISTORY 

NASA, then the National Advisory Commit- 
tee for Aeronautics (NACA), participation in 
the management of major aerospace pro- 
grams began shortly after World War II with 
the advent of the X series research aircraft. 


In these projects, essentially all of the tech- 
nical responsibility was delegated to one of 
the Centers, which were primarily expert in 
the technical area being explored (i.e., aero- 
dynamics, stability, control and structures) 
but did not have experts in the development 
of hardware. Accordingly, NACA entered 
into agreements with the Air Force or Navy 
to manage the actual development of the 
aircraft. The NACA Centers focused their 
direction on the technical requirements and 
performance characteristics to be demon- 
strated by the aircraft. The contractor’s 
responsibility was similar to that for the 
development of any aircraft, and the contrac- 
tor usually furnished test pilots for early 
demonstration flights. 

With the formation of NASA and the 
start of major manned space programs, it 
was necessary for NASA to develop the capa- 
bility to manage complex development 
activities. Very little SE&I capability exist- 
ed within the functional organizations of the 
NASA Centers. As a result, SE&I expertise 
was developed within each of the program 
offices. In particular, the Gemini program 
office was set up with autonomous capability 
to manage SE&I and direct the development 
contractor. 

With the advent of the Apollo program, 
SE&I was again managed from the project 
offices at the development centers. The 
project offices used specialized technical 
capability from the Center functional orga- 
nizations and prime contractors and initiat- 
ed the practice of hiring support contractors 
to assist in implementing SE&I. After the 
Apollo I fire, a review committee was estab- 
lished to determine the cause of the fire and 
recommend modifications to the program. 
One of the recommendations made was that 
NASA acquire a technical integration and 
engineering support contractor to assist in 
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accomplishing SE&I activity. The Washing- 
ton program office selected Boeing as the 
contractor and managed the contract for this 
activity; however, a large portion of the work 
force was located at the Centers. The con- 
tractor’s responsibilities included moni- 
toring the development and operational 
activities at the Centers, forming integrated 
assessments of the activity, and making 
recommendations to the program director for 
improvements. As the program matured, the 
contract focus was changed, and the contrac- 
tor provided a significant number of person- 
nel to directly support the Centers in SE&I 
and systems development activities. 

With the initiation of the Space Shuttle 
program and the adoption of the Lead Center 
concept, it was decided to manage the Level 
II integration activity, including SE&I, by 
providing a small management core within 
the program office and using many of the 
Centers’ functional organizations to provide 
technical support in a matrix fashion. At the 
Johnson Space Center (JSC), the lead person 
from the functional organization was gener- 
ally a branch head or an assistant division 
chief. JSC had a relatively large staff to 
draw from to provide the specific technical 
expertise and the level of effort needed to 
accomplish a given task. 

The Space Station Freedom program was 
started using the Space Shuttle program as a 
model. As the Lead Center, JSC managed in- 
tegration. Later, the Level II function was 
moved near Washington, D.C., under the 
deputy program director, and an indepen- 
dent contractor was brought in to assist the 
integration process. The Space Station Free- 
dom management organization will be dis- 
cussed in more detail in the next section. 

Program Management 
Organizational Structure 

A single NASA Center largely managed ear- 
ly NASA manned space flight programs, 
which allowed for a relatively simple organi- 
zational structure to accomplish program 


integration. JSC, then called the Manned 
Space Center, managed both development 
and flight operational aspects of the Mercury 
and Gemini programs with the checkout and 
preflight testing being performed by support 
elements at Cape Canaveral. 

Apollo became organizationally more 
complex (Figure 1). The spacecraft develop- 
ment was managed by JSC, the launch vehi- 
cle development by Marshall Space Flight 
Center (MSFC), the prelaunch activities by 
Kennedy Space Center (KSC) — by then an 
independent NASA Center — and the flight 
operations by JSC, In all of these programs, 
the responsibility for the development of the 
flight hardware was delegated to the 
Centers, and the interfaces between projects 
were intentionally kept as simple as possi- 
ble. The Washington office, under direction 
of the program director, was responsible for 
overall direction of the program including 
budgetary allocations, congressional rela- 
tions, and management of development 
issues between the project offices at the 
different Centers. The actual integration 
activity (SE&I) was coordinated by a series 
of panels and working groups in which 
individuals from the Washington program 
office served as either chairperson or 
members, with the program director over- 
seeing the activity. In the early programs 
(Mercury and Gemini), this activity was the 
responsibility of a single Center, and the 
Washington office was coordinated in an 
informal manner, but by the end of the 
Apollo program, the management of the pan- 
el and working group activity was relatively 
formal. In all of these programs the Center 
directors took an active part and personally 
felt responsible for the technical excellence 
of the work performed by their Centers. This 
intercenter involvement was accomplished 
primarily through the management council 
and major program reviews where Center 
directors personally participated in major 
decisions. 

In part of the Apollo program, the 
Washington office retained the responsibil- 



SE&I AND MANAGEMENT 



Figure 1 Apollo Program Management Organization 


performing the SE&I activity with the actu- 
al work being led by Bellcom, a division of 
Bell Laboratories. Ultimately, this approach 
was abandoned, at least partly because much 
of the Center director’s responsibility was 
lost, and an adversarial relationship be- 
tween the program director and the Center 
organizations developed. The execution of 
the SE&I was returned to the Centers with 
management and coordination of intercenter 
activities achieved through the use of work- 
ing groups, panels and management re- 
views. 

At the outset of the Space Shuttle pro- 
gram (Figure 2), the management of SE&I 
was markedly changed. Some of the more im- 
portant changes were adoption of the Lead 
Center management concept in which one of 
the participating Centers was delegated the 
management of program level integration 
including SE&I activities; the adoption of a 
configuration with functional and physical 


interfaces of much greater complexity; and 
the employment of one of the major hard- 
ware development contractors as the inte- 
gration support contractor. The complex 
interfaces made SE&I activity voluminous 
and involved and required the commitment 
of a larger percentage of the program re- 
sources to this activity. 

The Space Station Freedom program was 
structured so that the interface activity 
between the work packages was even more 
complex than that of the Shuttle program. 
Initially, the Lead Center approach to SE&I 
activity was adopted, but the implementa- 
tion was not effective. As a result of recom- 
mendations made by study groups and the 
committee reviewing the Challenger acci- 
dent, it was decided to transfer the responsi- 
bility for program integration activity, 
including SE&I, to the deputy program 
director in Reston, Virginia, and to bring on 
a contractor to provide program integration 
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Figure 2 Space Shuttle Program Management Organization 


support (Figure 3). Contractors having sig- 
nificant hardware development contracts 
were excluded from the contract competition. 
The first approach was to provide detailed 
management of SE&I activity by the Reston 
civil service personnel with the integration 
contractor providing support in executing 
the activity. Additionally, it was thought 
that much of the technical integration could 
be accomplished by having the work package 


contractors negotiate the definition and 
execution of much of the detailed integration 
process directly between themselves. This 
proved ineffective, however, because there 
was no clear lead responsibility and no clear 
way to resolve differences. As a result, 
because of the complexity of program in- 
tegration and the lack of in-depth backup ca- 
pability, this management approach has not 
been completely effective. 
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Figure 3 Space Station Freedom Program Management Organization (1990) 


Recently, it was decided to give the inte- 
gration support contractor direct responsibil- 
ity for the integration of the program but 
without authority to directly manage the 
work packages or their contractors. In an 
attempt to obtain more in-depth capability, 
the program director and deputy program 
director decided to execute the systems in- 
tegration portion of the SE&I activity at two 
of the Centers with the deputy director for 
integration physically located at one of the 
Centers. Since these functions were still re- 
tained organizationally within the program 
office, they were under the control of the dep- 
uty program director and, at the same time, 


had the advantage of drawing from the in- 
depth technical capability residing at the 
Centers. Simultaneously, the integrating 
contractor’s work force at the Centers was 
increased in both responsibilities and num- 
bers. 

Growing Program Complexity 

One of the major factors determining the 
efficiency of the integration of a program is 
the methodology used to delegate the engi- 
neering and development responsibilities to 
the project offices at the Centers. It has been 
found that less complex organizational 
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structures and simple interfaces are ex- 
tremely important to allow efficient manage- 
ment of SE&I activities. Each of NASA’s 
manned space programs has been organiza- 
tionally more complex than its predecessor 
and has had more complex interfaces. In both 
the Mercury and Gemini programs, the 
flight elements were divided into two parts, 
spacecraft and launch vehicle, and the phys- 
ical and functional interfaces between the 
two were quite simple. The induced environ- 
mental interfaces were somewhat more com- 
plex but readily amenable to experimental 
and analytical determination. 

The Apollo program involved a major in- 
crease in program complexity. The space- 
craft was divided into two project offices and 
the launch vehicle was divided into four 
project offices. By assigning the four launch 
vehicle projects to the same Center (MSFC), 
the integration between launch vehicle 
stages could be accomplished at the Center 
level. Similarly, both spacecraft projects 
were assigned to one center (JSC) for the 
same reason. The physical and functional in- 
terfaces between the spacecraft and launch 
vehicle, and hence between Centers, was rel- 
atively simple. In a 1971 paper titled “What 
Made Apollo a Success,” George Low stated: 
“Another important design rule, which we 
have not discussed as often as we should, 
reads: minimize functional interfaces be- 
tween complex pieces of hardware. Examples 
in Apollo include the interfaces between the 
spacecraft and launch vehicle and between 
the command module and the lunar module. 
Only some 100 wires link the Saturn launch 
vehicle and the Apollo spacecraft, and most 
of these have to do with the emergency detec- 
tion system. The reason that this number 
could not be even smaller is twofold: redun- 
dant circuits are employed, and the electrical 
power always comes from the module or 
stage where a function is to be performed. 
For example, the closing of relays in the 
launch vehicle could, in an automatic abort 
mode, fire the spacecraft escape motor. But 
the electrical power to do this, by design, 


originates in the spacecraft batteries. The 
main point is that a single person can fully 
understand this interface and can cope with 
all the effects of a change on either side of the 
interface. If there had been 10 times as many 
wires, it probably would have taken a hun- 
dred (or a thousand?) times as many people 
to handle the interface.” However, the oper- 
ational complexity of the Apollo vehicle 
demanded a more extensive integration 
activity between the Centers and for the first 
time posed the problem of accomplishing 
detailed technical coordination between 
Centers. 

One of the basic tenets of the Space 
Shuttle was to have an integrated vehicle 
that would recover the most expensive ele- 
ments of the system for reuse. This led to a 
design concept that placed a great majority 
of the electronics and major components of 
the main propulsion systems in the orbiter. 
This design concept led to very large 
increases in interface complexity between 
the program elements and, more important- 
ly, between the Centers. For instance, the 
number of electrical wires running between 
the external tank and the orbiter was more 
than an order of magnitude greater than 
between the spacecraft and launch vehicle of 
Apollo, and for the first time, major fluid 
systems ran across the interfaces. This 
represented a formidable increase in the ef- 
fort required to successfully accomplish the 
SE&I activity. As previously noted, a new 
program management structure (Figure 1) 
was adopted to accommodate the increase. 
The accomplishment of program-level SE&I 
was given to a “Lead Center.” The program 
director at Headquarters was still respon- 
sible for program budgetary control, Con- 
gressional relations and a technical staff 
sufficient to assure that the program tech- 
nical activity was being properly implement- 
ed. At JSC, which was the Lead Center for 
the Shuttle program, a Level II program 
office was established totally separate from 
the Level III orbiter project office located at 
the same Center. 
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The development of the flight hardware 
was delegated to four project offices with the 
orbiter office located at JSC, as mentioned 
above, and the other three — the Space Shut- 
tle main engine office, the external tank 
office, and the solid rocket booster office — 
located at MSFC. In addition to the hard- 
ware development project offices, a pre- 
launch processing office was formed at KSC. 
All of the project offices reported to the Level 
II program manager for all programmatic 
direction except budget allocation, which 
was retained by the program director at 
Headquarters. 

The SE&I activity was delegated to the 
systems integration office located within the 
JSC Level II office. The orbiter contractor, 
Rockwell International, was selected to be 
the integration support contractor, but to 
increase objectivity, the integration activity 
was made a separate exhibit to the contract 
and technical direction was delegated to the 
Level II systems integration office. The 
MSFC Space Shuttle project office appointed 
an integration manager to manage the 
integration of the Marshall Space Shuttle 


projects and to serve as the primary interface 
to the Level II systems integration office. 

The flight hardware developmental dele- 
gation of the Space Station Freedom 
program was formulated in an even more 
complex manner (Figure 4). End-to-end 
developmental responsibility for each of the 
major functional systems was delegated to 
one of four project offices called work pack- 
age offices in the Space Station Freedom 
program. Responsibility for assembling and 
delivering the flight hardware was broken 
down by launch elements, again assigned to 
one of the work package offices. Each of these 
launch elements incorporates components of 
most of the distributed systems, neces- 
sitating the transfer of an extremely large 
number of hardware and software items 
between work packages prior to their deliv- 
ery to the Government. This resulted in 
another major increase in the complexity of 
the program-level SE&I process and directly 
contributed to the difficulty of implementing 
a satisfactory SE&I process in the Space 
Station Freedom program. 



Figure 4 Space Station Integration Job 
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SE&I Scenario 

As a program develops from concept to oper- 
ational status, the characteristics of the 
SE&I activity vary greatly. Early in the pro- 
gram, conceptual SE&I is intimately in- 
volved in defining systems that will meet the 
overall program objectives and in evaluating 
the relative merits of each. This is usually 
accomplished in NASA manned programs by 
the civil service organizations, often in con- 
cert with Phase A/B contracts with industry. 
After the general systems specification has 
been developed and a detailed evaluation of 
systems concepts has been completed, SE&I 
provides a lead in the preparation of the pro- 
curement specifications for the Phase C and 
D activities and is usually directly involved 
in the source selection process. After award 
of the Phase C and D contracts and final 
selection of the design approach chosen for 
implementation, SE&I is responsible for pre- 
paring system-level technical specifications, 
which define the performance requirements 
to be satisfied by each of the major program 
elements. SE&I then develops the system 
characterization process to be used (dis- 
cussed in detail later) and starts an initial 
analysis cycle. The results of this cycle are 
extremely important in verifying the valid- 
ity of the system technical specifications and 
providing a technical basis for conducting 
the Program Requirements Review (PRR). 
After completion of the PRR and updating of 
the technical specifications, SE&I starts the 
definition of the interface control document 
tree and the initial document drafts. An- 
other system characterization cycle is start- 
ed, based on the updated specifications and 
the hardware and software concepts chosen 
to assess the adequacy of the proposed pre- 
liminary design approach. 

By this time in the program, the ad hoc 
organizational structure should be well in 
place and functioning routinely. The commu- 
nication and management overview provided 
by this structure of working groups, panels 


and reviews is central to accomplishing hori- 
zontal integration among the project offices 
and is discussed in more detail later. 

In preparation for the preliminary design 
review (PDR), SE&I defines the minimum 
content required in the PDR data packages 
and is responsible for preparing system-level 
documents supporting the Integrated 
System PDR. During the PDR process, SE&I 
representatives participate in the project- 
level reviews with particular emphasis on 
the compliance of the project to the system- 
level requirements. During the Integrated 
System PDR, emphasis is placed on assuring 
that the preliminary designs proposed by the 
projects are compatible across the interfaces 
and that the integrated system is capable of 
meeting the operational requirements of the 
program. The SE&I organization is inti- 
mately involved with the evaluation and dis- 
position of review item discrepancies (RIDs) 
that are submitted during the review. 

As a result of the PDR process, changes to 
the requirements and modifications to the 
preliminary design of the elements are incor- 
porated. A new characterization cycle is then 
initiated to evaluate the compatibility be- 
tween the modified requirements and pro- 
posed system capabilities. At this time, the 
drafts of the interface control documents are 
expanded and quantitative detail is added to 
assure that the documents are mature 
enough to become baseline requirements in 
the program. This maturation process inevi- 
tably results in the identification of physical 
and functional disconnects among the ele- 
ments and in a significant number of 
changes to the baseline. 

In a similar manner, the verification 
plans of the elements and the integrated 
system are refined and baselined. The 
responsibility for executing the test and ana- 
lysis required by the integrated system ver- 
ification plan are delegated to appropriate 
organizations that prepare detailed plans for 
accomplishing the assigned portions of the 
verification. 
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Detailed mission operational scenarios 
and timelines are prepared by the operations 
organizations, and the operations and SE&I 
organizations jointly conduct an analysis of 
the system capabilities to support the sce- 
narios. Concurrently, the acceptance test 
and prelaunch operations requirements and 
plans are prepared and delegated for execu- 
tion. 

In preparation for the critical design 
review (CDR), another system characteriza- 
tion cycle is performed, based upon the 
detailed design of the elements. This cycle 
typically uses mature models to synthesize 
the hardware and software systems and also 
incorporates the results of tests performed to 
that time. SE&I participates in the conduct 
of the CDR in a manner similar to that of the 
PDR. After completion of the CDR, the 
system requirements and design changes re- 
sulting from the CDR are incorporated into 
the documentation, and another complete or 
partial system characterization cycle vali- 
dates the decisions made during CDR. 

After CDR, the primary activity of the 
SE&l organization is to analyze test results 
and conduct analysis to verify the capability 
of the system that is being manufactured. 
Particular emphasis is given to verifying the 
interface characteristics of the elements as 
defined by the interface control documents. 
This activity directly supports the prepara- 
tion for the design certification review 
(DCR), and provides interface information 
necessary to allow acceptance of the system 
hardware and software by the Government. 

The DCR is conducted similarly to the 
PDR and CDR but addresses the as-built 
hardware and software. Successful comple- 
tion of the DCR certifies the acceptability of 
the as-built elements and the ability to be 
integrated into an overall system that will 
satisfy the initial program operational re- 
quirements. Final operational certification 
of the system is obtained by a combination of 
the DCR process and analysis of information 
obtained during early flight operation of the 
system. 


The SE&I organization’s participation 
throughout the program development cycle 
supports operational planning and real-time 
operations. SE&I is the repository of corpo- 
rate knowledge of the details of system 
capability, which is vital to the effective and 
efficient operation of the system. 

RELATIONSHIP OF SE&I TO OTHER 
PROGRAM FUNCTIONS 

To effectively accomplish the SE&I task, the 
SE&I management organization must main- 
tain good communications and obtain the 
support of other program office organiza- 
tions. Some of the more important interac- 
tions are discussed below. 

Configuration Management. The in- 
teraction between SE&I and configuration 
management is particularly strong. As the 
developers and keepers of the systems speci- 
fications, SE&I has an interface with the 
configuration management function that is 
extremely active throughout the life of the 
program. The SE&I office recommends the 
baselining of the technical requirements as 
they become sufficiently mature and then 
serves as the office of primary responsibility 
for defining and evaluating most of the pro- 
posed changes to this baseline. The SE&I of- 
fice, after proper coordination throughout 
the integration function, also recommends 
the processing of noncontroversial changes 
outside of the formal control board meetings, 
where appropriate. This significantly re- 
duces the board’s workload and conserves the 
time of the key managers who are members 
of the change control board. As significant is- 
sues are referred to the board, SE&I presents 
an analysis of the issues involved and makes 
appropriate recommendations for action. 

Program Control. SE&I supports the 
program control function in the development 
of program schedules and budgets. The key 
to making this support effective is the use of 
the SE&I logic networks and estimates of the 
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manpower required to accomplish the activi- 
ties. Because of SE&I’s interdisciplinary 
nature, SE&I can assist in planning activi- 
ties in many areas of the program. 

Early in the program, SE&I helps define 
the content and schedule milestones of each 
project to permit coherent development of 
project-level schedules and cost estimates. 
SE&I also provides program control with the 
engineering master schedules (EMS) and 
associated budget estimates for incorpora- 
tion in the overall schedule and budget 
system. SE&I also works with program 
control in planning major program reviews; 
provides technical leadership in conducting 
the reviews; and frequently chairs the 
screening groups and pre-boards. 

Operations. In all of the NASA manned 
space programs to date, the SE&I function 
has been managed in an organization differ- 
ent from the operations definition and plan- 
ning function. Although this is undoubtedly 
the best choice in the later phases of the pro- 
gram, it may result in a less thorough incor- 
poration of operational requirements in the 
systems specifications and other SE&I pro- 
ducts early in the program. It may be desir- 
able to combine the management of SE&I 
and operations in the same office early in the 
program and then separating them later, 
perhaps at the completion of the preliminary 
design review. The stated reason for separat- 
ing the functions in the past has been that 
they serve as a check and balance on each 
other; however, the separation also discon- 
nects the detailed interfaces between the two 
functions. 

SR&QA. The interactions between SE&I 
and the system reliability and quality assur- 
ance (SR&QA) functions depend on how 
responsibility for executing the program is 
delegated. If a large part of the SR&QA 
activity is accomplished within the SR&QA 
organization, SE&I is used as a reservoir of 
information or to perform specific tasks as 
requested by SR&QA. However, if the 


SR&QA office is responsible for setting the 
requirements for SR&QA activities and for 
evaluating the outcomes — while other orga- 
nizations are delegated the responsibility for 
executing the work — then SR&QA must de- 
fine and obtain baseline approval of task re- 
quirements, monitor execution of the task by 
SE&I, and evaluate the results to assure sat- 
isfactory achievement. 

The former mode of operation was exem- 
plified during the early Apollo program, in 
which the SR&QA activities were largely ac- 
complished within the SR&QA office using 
basic engineering information obtained from 
SE&I and other program organizational 
offices. Later in the Apollo program, the 
second mode of execution was adopted; the 
engineering offices, primarily SE&I, actual- 
ly performed the work and made a first-level 
analysis before formally transmitting the 
results to SR&QA for authentication. This 
latter method was considered more effective 
primarily because problems and discrepan- 
cies were often discovered by the originating 
engineering office and corrected even before 
the task was completed. 

SE&I Execution 

Techniques developed in past NASA manned 
programs have proven effective and have 
become an integral part of implementing 
SE&I activities. The following paragraphs 
describe, in no particular order, some of the 
most important techniques in planning and 
implementing new programs. 

Importance of SE&I Early in a Pro- 
gram. In the early stages of complex 
programs, comprehensive SE&I support 
helps determine the architecture to be used 
to delegate project responsibility. This is 
accomplished by dividing the program into 
the next lower level of management, the pro- 
ject offices. The primary outputs are compre- 
hensive and clear program requirement 
specifications, identification of major pro- 
grammatic interfaces, development of the ad 
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hoc SE&I management structure, definition 
of operating concepts, and preparation of 
initial specifications for the hardware to be 
delegated to each project office. 

The SE&I organization is responsible for 
managing technical integration both verti- 
cally between different levels of the man- 
agement organizations and horizontally 
across the organizations at each level. To 
efficiently achieve both dimensions of inte- 
gration, it is necessary to develop logic 
diagrams of the major SE&I activities to be 
accomplished by each of the organizational 
elements and then to determine the interre- 
lations between them. By developing these 
diagrams and playing them against different 
organizational structures, it is possible to 
evaluate the proposed organizations in 
simple terms and easily define the inter- 
actions between the organizational ele- 
ments, thus helping to choose the most 
efficient management structure. The impor- 
tance of the logic diagrams will be discussed 
later. 


Development and Use of Ad hoc Inte- 
gration Structure. To manage the defini- 
tion and implementation of the SE&I 
activities in manned space programs, NASA 
has developed an effective ad hoc organiza- 
tional structure. The structure consists of a 
series of reviews, panels and working groups 
that address the definition and management 
of integration functions throughout the pro- 
gram. Each organization has members who 
represent all of the organizations interested 
in the particular integration function being 
managed. In the Space Station Freedom pro- 
gram, the working group structure is formed 
by technical disciplines and distributed 
systems, such as Guidance, Navigation and 
Control, Robotics, and Loads and Dynamics. 
The panels are formed to address specific 
programmatic management areas (i.e., as- 
sembly requirements and stage definition, 
system design integration, and element de- 
sign integration) that span a number of orga- 
nizations. The reviews are formed to address 
relatively broad program areas as shown in 
Figure 5. 



Figure 5 Space Station Freedom Technical Review Structure (1990) 
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Each organization is responsible for de- 
veloping the integration plan in its area of 
responsibility, monitoring the execution of 
the tasks, identifying problem areas, and 
either resolving them or submitting them to 
the overall program management structure 
for resolution. Although these organizations 
by their nature do not perform work, the 
members, by working back through their 
functional organizations, greatly influence 
the work being accomplished in their par- 
ticular area of expertise. As rapport develops 
between members, many potential problems 
and issues are identified and resolved with- 
out being referred to formal management 
decision channels. In addition, the quality of 
the work materially improves. This ad hoc 
organizational structure also provides obvi- 
ous places for program elements to present 
any issue for deliberation and resolution. All 
of the panels and working groups support 
each review as needed, and submit their 
open issues to the most appropriate review 
for resolution. 

The reviews address broad issues and 
serve as a communication channel between 
the panels and the working groups. Since the 
reviews cover all of the panels and working 
groups, they provide an excellent way of 
assessing and recommending to manage- 
ment the interdisciplinary priorities of the 
program. 

Chairpeople of the panels and working 
groups are the most qualified individuals 
available in a particular discipline. Only sec- 
ondary consideration is given to selecting a 
person from a specific organizational ele- 
ment. As a result of their recognized stature, 
the chairpeople provide leadership, which 
makes their recommendations and decisions 
more credible. The panels and working 
groups also call in outside expertise when 
needed, but such outside inputs are filtered 
by the panels and working groups before 
making a recommendation to the reviews or 
other management organizations. 


Internal vs. Matrix SE&I Staffing. As 
already noted, SE&I has been staffed and 
accomplished in different ways in different 
NASA manned programs. In the early 
manned space programs, the personnel 
required to accomplish the SE&I activity 
were assigned directly to the program and 
project offices. During the Apollo and Shut- 
tle programs, the program office had only the 
people necessary to manage the SE&I activ- 
ity, and most of the work was accomplished 
by technical experts assigned from the 
Centers’ functional organizations in a 
matrix fashion. Although each method has 
its advantages and disadvantages, the ma- 
trix approach generally has more advan- 
tages in that manpower can be increased or 
decreased as needed by pulling support from 
the matrix organizations without reassign- 
ing the people involved. The primary disad- 
vantage is that the leader of a particular 
area does not report functionally to the pro- 
gram or project office, which means that the 
line of direction is not as strong. The 
importance of this negative factor, however, 
is inversely proportional to the working 
relationship between the organizations. In 
the Space Shuttle program, this relationship 
and the matrix approach worked well. In 
other programs, the relationship was not as 
good and direction through the matrix was 
less effective. On occasion, program man- 
agement appointed all panel and working 
group chairpeople from the program office 
staff, giving less regard to the individual’s 
personal qualifications. This led to a marked 
decrease in the stature of the ad hoc 
structure, which then resulted in a lack of 
support from the functional organizations 
and a decrease in the quality of the integra- 
tion activity and products. As in many areas 
of SE&I, effective implementation relies 
heavily on the quality of the leadership and 
the maintenance of free and open communi- 
cations among the organizations involved. 
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Logic Networks. As the NASA manned 
space programs have become increasingly 
complex, it has become difficult to define the 
specific content and tasks needed to accom- 
plish the SE&I function. Central to the de- 
velopment of a comprehensive SE&I plan is 
the development of detailed logic networks, 
which form the basis for planning, executing 
and evaluating the SE&I activities. 

As used in the Space Shuttle program, 
logic networks covered all of the SE&I activi- 
ties that had to be accomplished by all 
elements of the program organization. Thus, 
these networks were able to interrelate 
SE&I activities both vertically and horizon- 
tally throughout the program management 
structure. The basic summary logic net- 
works were developed for the entire program 
duration, to identify all major activities 
required as a function of time, and were 
instrumental in developing cost and man- 
power forecasts for the entire duration of the 
program. Detailed logic networks were then 
prepared for the near-term in the Shuttle 
program for 12 months, identifying in 
greater detail the specific activities to be 
accomplished by each organizational ele- 
ment during that period. The networks were 
revised every six months to extend the detail 
planning horizon; in addition, the summary 
networks were reviewed and modified as 
needed on an annual basis. The logic 
networks were a primary input to the devel- 
opment of the engineering master schedules 
discussed in the next paragraph. 

Engineering Master Schedules (EMS) 
and Associated Dictionary. The activities 
identified in the SE&I integration logic net- 
works were then assigned to specific organi- 
zations for execution and presented as a 
schedule for each organization involved. By 
using a numbering system for the activities, 
the logic network and the schedule could be 
easily correlated. The schedules allowed cost 
and manpower estimates to be prepared for 
each organization and provided an excellent 


means of determining status and managing 
activities in real time. 

Associated with the EMS, a dictionary 
was prepared with an entry for each activity. 
Each entry identified all input information 
required to allow the accomplishment of the 
activity; described the contents of the pro- 
ducts; and identified the primary user of 
each product, the scheduled completion date, 
and the person responsible for preparing the 
product. The EMS and the dictionary were 
the primary tools for defining and communi- 
cating SE&I activities throughout the entire 
program structure. 

As would be expected, the content of the 
EMS changes character over the life of the 
program and accordingly, requires various 
technical capabilities over time. Early in the 
program, the design activities involve a 
large number of trade studies and the devel- 
opment of synthesis tools to be used in evalu- 
ating the capabilities of the proposed design. 
As the program matures and the design so- 
lidifies, the activities become more involved 
with exercising the system models, conduct- 
ing tests and analyzing data. As the flight 
phase approaches, the activities are pre- 
dominated by operational considerations, in- 
cluding the development of operational data 
books, mission requirements, certification of 
system readiness, and support of mission 
planning and real-time mission operations. 

System Characterization Process. A 
major SE&I activity throughout the program 
life span is the assessment of the capability 
of the system to meet specified requirements. 
In the NASA manned space program, this 
has been accomplished in an analytic sense 
by synthesizing the vehicle characteri- 
zations in the form of either models or 
simulations, and then developing detailed 
performance characterizations by exercising 
the models against selected mission time- 
lines and significant mission events. 

The methodology used to perform the sys- 
tem synthesis is central to the development 
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of the logic networks and schedules described 
earlier. An examination of the system usual- 
ly reveals scenarios useful in conducting the 
overall system evaluation; after selecting 
the most desirable scenario, it forms the nu- 
cleus of the overall SE&I logic. In the Space 
Shuttle program, the scenario chosen was (1) 
develop the necessary models and simula- 
tions; (2) determine the structural modal 
characteristics; (3) determine the loads on 
each of the system elements; and (4) perform 
stress analysis of the system when subjected 
to these loads. Using this scenario it was rel- 
atively easy to define and interrelate the 
SE&I activities of other disciplines, such as 
GN&C, propulsion, and thermal, among 
others. After defining all of the required ac- 
tivities, a document was prepared to identify 
the models to be used, and the mission events 
to be analyzed and to define the configura- 
tion to be used. The sequence described 
above formed an analysis cycle of a specific 
configuration subjected to specific operation- 
al requirements. In the Shuttle program, it 
was termed an integrated vehicle baseline 
characterization cycle (IVBC). As previously 
described in the SE&I scenario, several char- 
acterization cycles are needed during the 
program: as the program matures, the cycles 
have additional synthesis detail, more de- 
finitive configuration information, and bet- 
ter operational information. 

At the completion of each of the charac- 
terizations cycles, system deficiencies are 
identified and modifications to either the 
system specifications or the requirements 
are made. For program management pur- 
poses, it is usually convenient to schedule 
the completion of one of the characterization 
cycles to occur just before each of the major 
program-level review milestones. 

Program Reviews. SE&I has a large 
input to each of the program-level reviews, 
such as system requirements review, pre- 
liminary design review, critical designre- 
view, design certification review, and flight 
readiness reviews. As mentioned above, com- 


pletion of one of the system characterization 
cycles is an excellent indicator of whether 
the system design meets the specified 
requirements. The engineering master 
schedule gives a graphic representation of 
whether the integration progress is being 
achieved. Reports produced by the SE&I ac- 
tivity, such as resource allocation status and 
margins, interface control document status, 
design reference mission maturity, and sys- 
tem operational data books indicate the 
maturity of the element participation in the 
system-level SE&I process. 

Design Reference Missions. Most of the 
manned space programs had to be capable of 
performing a relatively large number of di- 
verse missions, and the specifications are 
written to allow hardware and software sys- 
tems and elements that are flexible enough 
to satisfy all of the missions. For analytical 
purposes, however, it is convenient to define 
and adopt one or more design reference mis- 
sions (DRMs) that stress all of the systems 
capabilities to a significant extent. The 
DRMs are used as the primary mission re- 
quirements in the system characterization 
cycles, and in evaluating the ability to meet 
performance specifications. In addition to 
evaluating the baselined configuration 
against the DRMs, other specification 
requirements are evaluated by the accom- 
plishment of specific analyses or tests, as 
necessary. 

The DRMs also allow the user community 
to evaluate whether the system is capable of 
meeting specific user needs and whether 
these needs are specifically in the system 
specifications. The DRM is used by mission 
planners to determine the system’s capabil- 
ity of performing any specific mission under 
consideration. 

Verification. Verification plays a major 
role in program planning and in the ultimate 
cost of the system. Although most of the 
verification is delegated to projects, SE&I is 
responsible for identifying the overall 
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verification requirements and specific 
system-level verification tests and simula- 
tions, which frequently require specialized 
facilities and significant amounts of system 
hardware and software. Since these system- 
level verification tests are frequently com- 
plex and expensive, planning for them needs 
to start very early in the program. The 
system-level verification network is devel- 
oped as an integral part of the program SE&I 
logic networks and is baselined early in the 
program. 

Final verification of some system require- 
ments can only be accomplished in the real 
flight environment, and these are demon- 
strated in early operations before final certi- 
fication of system operational capability is 
accomplished. It is also important to inte- 
grate the system-level verification planning 
and the operations planning to promote the 
maximum synergism possible between sys- 
tem verification and operational training. 

In manned space programs, all of the 
major system level verification tests have 
been assigned to program or functional orga- 
nizational elements other than SE&I for 
implementation. This has helped to assure 
that the management of SE&I can remain 
objective in the evaluation of overall certifi- 
cation adequacy. 

DCR Process. One of the most signifi- 
cant activities of SE&I its role in the certifi- 
cation of the system design prior to the start 
of the flight operations and then later, prior 
to committing the system to operating 
throughout the entire design envelope. SE&I 
is instrumental in setting the overall re- 
quirements for the DCR and is directly re- 
sponsible for the system-level portion of the 
review. This process becomes the final major 
system characterization cycle, using a syn- 
thesis of the as-built vehicle hardware and 
software capabilities and results of tests and 
analyses. DCR results also form the basis for 
the system operational data books that are 
used to plan and conduct the operational 
phase of the program. The DCR requires that 


all system requirements be evaluated 
against all of the as-built system capabil- 
ities, and where possible, the system mar- 
gins are quantified to assist the operations 
organization in planning and conducting 
flight operations. 

ICD Development. As the program 
management organizational structure is 
determined and responsibility for developing 
hardware and software is delegated, it is nec- 
essary to start the development of the 
interface control document (ICD) tree, which 
identifies each required ICD and the content 
to be presented. As previously noted, the di- 
vision of program activities to minimize the 
number and complexity of interfaces has a 
strong influence on the overall program cost 
and the ability of the program to meet sched- 
ules. The early development of strawman 
ICD trees can greatly assist in optimizing 
the overall program management structure. 
As the program progresses and the system 
configuration becomes better defined, the 
content of each ICD is developed in more de- 
tail and ICD working groups are formed to 
quantify the environmental, physical, func- 
tional and operational characteristics in 
detail. In most manned programs, the ICDs 
have been baselined at a relatively early 
point in the program and have usually con- 
tained a large number of TBDs (to be 
determined). After baselining the ICDs, 
working groups continue their work to arrive 
at specific values for each of the TBDs and to 
continually assess the adequacy of the ICDs 
as the design matures. 

The ICDs are primary documents at each 
program review and provide a basis for eval- 
uating the adequacy of the items being 
reviewed to satisfactorily function as part of 
the total system. 

Program Management Organization- 
al Structure. The efficiency of program 
management is greatly influenced by the 
organizational structure selected. Organi- 
zational structures that are compact and 
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simple promote effective program manage- 
ment. Compactness is measured vertically 
by the number of levels of the program man- 
agement organization and horizontally by 
the number of organizations at each level. 
Each additional organizational element 
significantly increases the manpower and 
costs of achieving program integration, in- 
cluding SE&I. If each organizational ele- 
ment must interface with all others in the 
program, the number of interfaces increases 
rapidly as organizations are added. Adding 
management levels increases the complexity 
for delegating the execution of the program. 
This factor was evident to the Augustine 
Commission in their recent summary report 
The Future of the U.S. Space Program, in 
which they recommended that “multicenter 
projects be avoided wherever possible, but 
when this is not practical, a strong and inde- 
pendent project office reporting to Headquar- 
ters be established near the Center having 
the principal share of the work for that 
project; and that this project office have a 
systems engineering staff and full budget 
authority.” 

In addition to keeping the management 
structure compact, it is also very important 
to select an architecture that divides the 
program into project offices, to enable simple 
interfaces between projects and delegation 
that is all-encompassing. All of the deliver- 
able hardware assigned to a given project 
should be the responsibility of that project to 
design and manufacture. In all manned 
programs prior to the Space Station, there 
was little transfer of hardware and software 
between projects — with one exception, that 
being the development flight instrumenta- 
tion in the Apollo program. 

Early in Apollo, a decision was made to 
establish a civil service project office to 
develop, procure and deliver the specialized 
development flight instrumentation to the 
prime spacecraft contractors for installation 
and integration in the early spacecraft. 
Coordination of the large volume of interface 
information required the development and 


maintenance of the complex bilateral sched- 
ules and support required. The complexity of 
providing support after the transfer of the 
instrumentation was a significant manage- 
ment problem throughout the entire time 
that the development flight instrument was 
used. In the Space Station Freedom program, 
considering the many hardware and soft- 
ware items that must be passed between 
work packages, it will be difficult to develop, 
coordinate and maintain all of the interface 
information required. 

Objectivity In Management. To pro- 
mote objectivity in managing SE&I, one of 
the basic ground rules in the Shuttle pro- 
gram was that the SE&I function would not 
be responsible for the development of any 
flight hardware or software products; thus, 
they had no conflicting pressure to make 
their development job easier at the expense 
of another organization. It was found that 
any bias, either perceived or real, immedi- 
ately brings the objectivity of management 
into question and rapidly destroys the confi- 
dence between organizational elements. 

Need for Good Communication. The 
nature of SE&I is such that most of the pro- 
gram elements and many other agency orga- 
nizations are involved in the execution of 
SE&I tasks. To facilitate accomplishment of 
the work, the importance of free and open 
communication cannot be overstressed. One 
of the ways of accomplishing this is “to live 
in a glass house.” All decisions and, of equal 
importance, the logic behind those decisions 
must be communicated to all parties 
involved if they are to understand their role 
and how it fits into the overall picture. All 
parties must feel that their inputs are in- 
cluded in the decision-making process. This 
openness, and the accompanying feeling of 
vulnerability, is often not welcomed and 
requires faith and confidence between the 
organizations involved. The fact that mis- 
takes will be made must be accepted, and all 
organizations involved must constructively 
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assist in correcting them. Frequent open 
meetings of the ad hoc organizational ele- 
ments described above have proven to be an 
effective tool in developing rapport between 
peers and communicating information and 
decisions throughout the program structure. 
As noted earlier, however, such meetings 
become increasingly time-consuming and 
expensive as the complexity of the organiza- 
tional structure is increased. 

Importance of Margins. At the time 
programs are initiated, they are frequently 
sold on the basis of optimistic estimates of 
performance capability, cost and schedules. 
This often results in reducing margins to low 
levels at program initiation and solving 
early program costs and schedule problems 
by reducing weight, power and other re- 
source margins. As a consequence, margins 
are reduced to zero or negative values early 
in the program, making it necessary to modi- 
fy the program to either reduce requirements 
or introduce program changes that will 
reestablish positive margins. The recovery of 
the margin inevitably leads to significantly 
higher ultimate program costs in both 
dollars and days. Minimum life cycle costs 
are achieved by holding relatively large 
margins early in the program and then 
allowing them to be expended at a prudent 
rate during the program life cycle. 

Things That Have Worked Well 

In the management of the manned space pro- 
grams’ SE&I activities, several approaches 
have been particularly successful. Some of 
the most important, have been discussed pre- 
viously but are readdressed here because of 
their assistance in the management of SE&I. 

Ad hoc Organizations. The use of ad 
hoc organizations to coordinate SE&I activi- 
ties has proven to be a valuable tool. The 
effectiveness of SE&I depends heavily on 
good communications between organizations 
and the assurance that all organizational 


elements take a common approach to the 
implementation of SE&I. This is difficult to 
accomplish using the normal program office 
organizations because they cannot directly 
address inter-organizational communica- 
tions and have difficulty managing across or- 
ganizational lines. The ad hoc organizational 
structure, on the other hand, is made up of 
specialists from each of the affected organi- 
zations, and their activities directly promote 
inter-organizational communications. Using 
this technique, technical peers can plan and 
monitor the execution of specific SE&I ac- 
tivities. When a resolution cannot be reached 
within the ad hoc organization, the issue can 
be referred to the proper program manage- 
ment office for decision. 

Standard Organization Structure 
within the Program and Project Offices. 
During the Apollo program, the program di- 
rector decided to have all of the program 
management offices at both Level II and 
Level III adopt a standard organization 
structure: five offices reported to the 
program manager and the same five offices 
reported to each project manager. This tech- 
nique assured that the work breakdown 
structure was similar for all offices, that 
direct counterparts could be identified in 
each of the offices, and that budget alloca- 
tions flowed down in a uniform and predict- 
able manner. All of these features resulted in 
less cross-linking between organizations and 
made the required program management 
activity more rational and predictable. 
Although the specific office structure chosen 
would be different for each program, having 
uniformity between the Level II and Level 
III management offices should be considered 
for future programs. 

System Characterization Cycles. Con- 
structing the SE&I plan and identifying the 
required tasks is a very complex under- 
taking in large programs. As previously 
described, it is best to have a well-defined 
core of activity that, when completed, will 
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characterize the capability of the system to 
meet the specified requirements. Analysis of 
the results reveals deficiencies and allows 
modifications to either the requirements or 
the system design to be identified, thus as- 
suring an adequate margin of performance. 
Building on this core analysis cycle, it is rel- 
atively easy to plan the other SE&I tasks in 
a consistent manner, and create a complete 
characterization of the system capability. 

Matrix Management Organizational 
Approach. The concept of staffing the 
program management office with a small 
number of people who serve as managers 
only and then augmenting their capability 
with personnel drawn from other Center or- 
ganizations in a matrix fashion has signifi- 
cant advantages. Manpower can be brought 
in from the organizations only when it is 
actually needed, and the technical composi- 
tion can be changed over time to satisfy pro- 
grammatic needs. The quantity of personnel 
can be augmented to meet program needs, 
i.e., during major program reviews; the per- 
sonnel involved can be assured of a career 
path in their parent organization; and the 
individuals involved can continually replen- 
ish their expertise by participating in the 
R&D activities of their parent organization. 

This mode of operation has been quite 
successful and has demonstrated several 
additional advantages, such as reducing fric- 
tion and undesired competition between the 
program office and Center functional organi- 
zations, improving technical communica- 
tions across programs being implemented 
simultaneously, and providing an efficient 
way of phasing the development program 
into an operational role. In particular, the 
assignment of program-level SE&I to a Lead 
Center, coupled with the execution of this 
assignment using Center functional organi- 
zations in a matrix fashions, allows the pro- 
gram to take advantage of both the quality 
and quantity of technical expertise available 
throughout the Center. 


Use of a Prime Development Contrac- 
tor to Provide SE&I Support. In the 
Shuttle program, the SE&I support contrac- 
tor was also the prime contractor for the de- 
velopment of the Space Shuttle orbiter. 
Although there was considerable concern 
about the ability of the contractor to main- 
tain objectivity in supporting SE&I, this con- 
cern was reduced to an acceptable level by 
separating the direction channels of the 
development and integration activity both 
within NASA and within the contractor’s 
organization. The support contract was also 
set up with an award fee structure in which 
SE&I was responsible for providing inputs 
for the SE&I activities. There were many 
advantages in this arrangement: 

a) The integration personnel were familiar 
with one of the major program elements 
and did not need to become familiar with 
that element or the general program 
structure. 

b) Technical experts could be made avail- 
able for both activities as needed. 

c) Many of the synthesis tools required by 
both activities were similar, and fre- 
quently one model could be used for both 
purposes with only minor modifications. 

d) Uniformity in approach assured ease of 
comparison of results from both project- 
level and program-level activities. 

The management of SE&I in NASA man- 
ned space programs has developed over the 
last 30 years to satisfactorily integrate 
relatively complex programs. Some of the 
approaches and techniques described in this 
paper may be helpful in integrating future 
programs. Careful consideration of the 
organizational structure and systems archi- 
tecture at a start of a program has an 
overriding effect on the effort required to 
accomplish the SE&I activity. 
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